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A METHOD AND APPARATUS FOR CLEARING A LARGE 
NUMBER OF CONNECTIONS IN AN ATM NETWORK 



5 FIELD OF THE INVENTION 

The present invention relates generally to the field of Asynchronous Transfer 
Mode (ATM) data networks and more specifically to a method of and an apparatus for 
clearing connections in an ATM data channel. 

10 BACKGROUND OF THE INVENTION 

Asynchronous Transfer Mode (ATM) is a packet switching network technology 
based on switching fixed length packets of data between transmission devices, a 
transmission device (hereinafter referred to as a node) comprehending a gateway, a 
router, and a switch, and referred to alternatively as a node, or respectively as a gateway, 

15 router, or switch. 

An ATM network typically provides a number of interconnected nodes which 
receive data fi"om network nodes and forward that data through other network nodes to an 
ultimate destination. In general, a node includes a plurality of ports that are coupled to at 
least one input and output line, each port connecting the node to another node of the 

20 network, and allowing for the routing of data between the connecting nodes. 

ATM based networks can maintain a large number of connections per port and the 
task of clearing (disconnecting) all connections of a port is inefficient using the ATM 
Forum provided prior art. In order to clear a Virtual Channel, the ATM Forum prior art 
provides a message called RELEASE and a corresponding message called RELEASE 



25 COMPLETE. Well known to those skilled in the art, the RELEASE and the RELEASE 




COMPLETE message are each transmitted along the signaling channel between 
connecting nodes. A first network node issues a separate RELEASE message for each 
connection, and transmits the RELEASE message to connecting nodes for propagation 
along the network for eventual reception by a second network node. The second network 
5 node then initiates and transmits a corresponding RELEASE COMPLETE message as an 
acknowledge to the RELEASE message for that separate connection that is transmitted 
across the network to the first network node. 

With reference to Figure 1, an ATM data pathway comprises a connected gateway 
102, node 104, node 106, node 108, and gateway 110, and illustratively carries an 

10 estabUshed specific connection between gateway 102 and gateway 110. If a calling party 
(not shown) that is connected to gateway 102, chooses to initiate a disconnect process, 
the calling party transmits a disconnect message to gateway 102. Gateway 102 responds 
to the disconnect message by initiating a RELEASE message that is transmitted fi-om 
gateway 102 across the pathway to gateway 110, which responds to the reception of the 

15 RELEASE message by transmitting to gateway 102 a corresponding RELEASE 

COMPLETE message for only that specific connection. The RELEASE COMPLETE 
message transmitted across the pathway individually releases the specific connection on 
gateway 110, the nodes 108, 106, and 104, and the gateway 102. 

Now referring to Figure 2, an ATM network 200 includes a router 202, nodes 

20 204, 206, 208, 210, 212, 214, and router 216, comprising a separate transmission path 1 
that includes router 202-node 204-node 206-node 208-router 216; and a separate 
transmission path 2 that includes router 202-node 204-node 210-node 212-node 214-node 
208-router 216. Suppose that there are twenty estabHshed connections between router 
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202 and router 216 such that the ten connections take path 1, and a remaining ten 
connections take path 2. Now suppose that the trunk that connects node 204 and 206 is 
cut, so that each of the ten connections along path 1 should be released. Currently, 
according to ATM Forum prior art, node 204 must send ten separate RELEASE 
5 messages, one for each connection, towards router 202, and node 206 must send ten 
separate RELEASE messages towards router 216 via node 208, as both node 204 and 
node 206 sense the cable cut. Routers 202 and 216 each send back a separate RELEASE 
COMPLETE message for each of the separate ten connections. Or suppose that that the 
trunk that connects node 212 and node 214 is cut, so that each of the ten connections 
% 10 along path 2 should be released. Currently, according to ATM Forum prior art, node 212 
in must send ten separate RELEASE messages towards router 202 via nodes 210 and 204 

Q and node 214 must send ten separate RELEASE messages towards router 216 via nodes 

ip 214 and 208 as both node 212 and node 214 sense the cable cut. Routers 202 and 216 

each send back a separate RELEASE COMPLETE message for each of the separate ten 
15 connections. 

™ As illustrated, because the current RELEASE and RELEASE COMPLETE 

messages together clear only a single connection, in order to clear a port all data 
connections at the port must be cleared separately by issuance of multiple RELEASE and 
RELEASE COMPLETE messages, one pair for each connection. If there is network 
20 congestion, a connection clearance in accordance with the ATM Forum prior art may 
require a retransmission. Thus a single connection, while requiring a minimum of two 
messages, may require more than two messages per connection, and a port having more 
than "n" connections while requiring a minimum 2 "n" messages, may require many 
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more messages than that nimiber. Each RELEASE and each RELEASE COMPLETE 
message consumes network resources including processor time, memory time, processor 
bus time, node transmission bus time, and node switch time; all of which impact overall 
node transmission bandwidth and hence network performance. 
5 The prior art RELEASE and RELEASE COMPLETE messages consume "n" 

times the resources in clearing a port having "n" active connections by requiring "n" 
separate message pairs, than a disconnection method and apparatus that has only a single 
pair of clearing messages for all the port connections. Also, because the number of ATM 
layer 3 messages exchanged across ATM switches is significantly reduced (by a factor of 
J 10 1/' V) for an ATM network by having 2 rather than 2 "n" messages, the cumulative task 
Iff context switch time is reduced in an ATM switch processor. Also, the number of 

C3 outstanding timers consuming node processor and memory time is reduced because only 

1 timer is now required rather than n timers. The time for exchange of buffers between 
processor modules is also reduced. In a high-capacity ATM network, the reroute time is 
15 also reduced because the connections on a port can be disconnected by a single pair of 
Q messages, rather than a pair of messages for each individual connection. Also, the 

number of messages exchanged between nodes is reduced which reduces the congestion 
in a high capacity network. In a network comprising of large number of nodes, with a 
large number of connections (of the order of hundreds of thousand), to send/receive up to 
20 4 messages per connection per node is an enormous burden on the network resources. 
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SUMMARY OF THE INVENTION 

Briefly stated, a method is disclosed of clearing a plural number of connections 
from each of two connected nodes by clearing the first connections from the first node, 
generating a single first message from the first node to the second node identifying the 
5 connections, clearing the connections from the second node in response to the receipt of 
the first message, and generating a second message from the second node to the first node 
identifying the connections cleared by the second node in response to the second node 
receiving the first message. Additionally, a database is taught that maintains the 
connections cleared by the first node for which a first message type has been issued, as 
10 well as connections cleared by the first node for which a first message type has been 
issued and for which a second message type has not yet been received from the second 
node. 

Briefly stated, an ATM node is disclosed having circuits for generating and 
interpreting each of the two messages, and maintaining a database of connection status. 
15 Each of the first and second message type signal a clearing of a pluraUty of inter-nodal 
connections. These messages each have an identification of the connections cleared/to 
be cleared, as well as a transaction identification, and an identification in the message of 
message type in a location consistent with an ATM message type. 

Other features and advantages of the present invention will be apparent from the 
20 accompanying drawings and from the detailed description that follows below 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example and not limitation in the 
figures of the accompanying drawings, in which like references indicate similar elements. 

Figure 1 portrays an embodiment of an ATM network having a single connection 



Figure 2 portrays an embodiment of an ATM network having an illustrative ten 
connections along a first node path, and ten connections along a second node path. 

Figure 3 portrays an embodiment of the format of a BULK RELEASE message. 

Figure 4 portrays an embodiment of the format of a BULK RELEASE 
10 COMPLETE message. 

Figure 5 portrays the structure of an embodiment of a connection database having 
connection records for connections included in a BULK RELEASE message. 

Figure 6 portrays the structure of an embodiment of a connection database having 
connection records for connections for which a BULK RELEASE message has been 
15 generated but for which a BULK RELEASE COMPLETE message has not yet received. 

Figure 7 portrays a flow chart of an embodiment of a method of clearing the 
connections on a node that connect to a peer node, generating a BULK RELEASE 
message to the peer node, sending the BULK RELEASE message to the peer node, and 
updating a connection database for the single transaction. The order of description 
20 should not be construed as to imply that these operations are necessarily order dependent. 

Figure 8 portrays a flow chart of an embodiment of a method of clearing the 
connections on a node that connect to a per node, generating a BULK RELEASE 
COMPLETE message to the peer node, sending the BULK RELEASE COMPLETE 
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between two end points. 
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message to the peer node, and updating a connection database for the single transaction. 
The order of description should not be construed as to imply that these operations are 
necessarily order dependent. 

5 DETAILED DESCRIPTION 

In the following description, various aspects, configurations, and details of the 
present invention will be described. However, it will be apparent to those skilled in the 
art that the present invention may be practiced with only some or all aspects, 
configurations, and details of the description. In other instances, well known features are 

10 omitted or simplified, including apparatus and method steps, in order not to obscure the 
present invention. Various operations will be described as multiple discrete acts 
performed in turn in a manner that is most helpful in understanding the present invention. 
However, the order of description should not be construed as to imply that these 
operations are necessarily order dependent, in particular, the order the acts are presented. 

15 Any necessary ordering is altematively expressly mentioned or will be understood by 
those skilled in the art. Furthermore, the phrases "in one embodiment" and/or "an 
embodiment" are used repeatedly. However the phrases do not necessarily refer to the 
same embodiment, although they may. 

The present invention also relates to apparatus including circuits for performing 

20 the operations herein. This apparatus may be specially constructed for the required 
purposes, or it may include a general purpose computer selectively activated or 
reconfigured by a computer program stored in the computer. The method and apparatus 
taught herein are preferably implemented in software that is both stored on a node's 
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conventional memory and executed on the node's conventional processor(s). It is also 
within the specific contemplation of this invention that the method and apparatus taught 
herein are implemented on a non-programmed digital circuit, including a finite state 
machine in whole or in part. Such a computer program may be stored in a computer 
5 readable storage medium. A machine readable storage medium includes any mechanism 
that provides (i.e. stores and/or transmits) information in a form readable by a machine 
(e.g. a computer). For example, a machine-readable medium includes read only memory 
(ROM), random access memory (RAM), magnetic disk storage media, optical storage 
media, flash memory devices, electrical, optical, acoustical or other form of propagated 

10 signals (e.g., carrier waves, infirared signals, digital signals, etc.), etc.. The algorithms 
and displays presented herein are not inherently related to any particular computer or 
other apparatus. Various general purpose systems may be used with programs in 
accordance with the teachings herein, or it may prove convenient to construct more 
specialized apparatus to perform the required method steps. The required structure for a 

15 variety of these systems will appear fi-om the description below. In addition, the present 
invention is not described with reference to any particular programming language. It will 
be appreciated that a variety of programming languages may be used to implement the 
teachings of the invention as described herein. 

A novel ATM layer 3 (or any other layer that may be responsible for clearing 

20 connections) message pair for signaling a clearing of at least one point-to-point 
connection between two specific nodes includes a first message that the inventors 
preferably term a BULK RELEASE (BR) message and a corresponding second message 
that the inventors preferably term a BULK RELEASE COMPLETE (BRC) message. 
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The terms BULK RELEASE and BULK RELEASE COMPLETE shall be used in this 
description hereafter. These messages are preferably enabled and disabled using a 
configuration option, wherein each node has the support software already installed. On 
an ATM node, provisioning is preferably done using an IP cormectivity into the node or 
5 alternatively through a console terminal. A command line interface command such as 
"cnfBulkRleaseFeature enable/disable" can be executed on the ATM node. After the 
command is executed, the option selected is stored in the ATM node database. Because 
the enablement and disablement is user configurable, the nodes are interoperable with 
non-BR/BRC nodes using ATM RELEASE and RELEASE COMPLETE messages. 
3 10 Referring to Figure 3, an embodiment of the BULK RELEASE message 302 

m includes an ATM User-to-Network Interface (UNI) formatted message. It is specifically 

5 contemplated that the number of connection records (Lists) transmitted by a BULK 

RELEASE message may be limited to less than the number of connections to be cleared 
ITi on a port. In such case, it is specifically contemplated that a plural number of BULK 

yS 15 RELEASE messages shall be issued and shall be exchanged between nodes in order to 
Q clear each plausible connection. While a specific preferred embodiment of a BULK 

RELEASE message is disclosed, the invention is specifically not dependant upon any 
specific embodiment of a BULK RELEASE message. The purpose of the BULK 
RELEASE message is to notify another network node that a clearance of specified 
20 connections is to occur or has occurred on a referenced node, and/or that a clearance of 
specified connections is to occur on the another node, and/or to provide the data for a 
confirming message to be issued by the another node, as well as to optionally provide the 
data to access the connection and transaction data in a memory, and to store data in the 
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memory associated with the transaction and/or connection(s). Thus, a BULK RELEASE 
message should be in a format that will be distinguished and read by other network 
nodes, and should transmit the necessary information. There is no specific necessary 
embodiment of the BULK RELEASE message. 
5 The BULK RELEASE message is generated by a node upon an initiating (or 

triggering) event as taught with reference to Figure 7 below. The BR message includes a 
conventional message format having both a header 304 and a payload 306. 

The BULK RELEASE message 302 header 304 includes a Protocol Discriminator 
record 308. The Protocol Discriminator record 308 content indicates whether or not the 

10 message is an ATM signaling CALL control message. The indication of this record is 
useful upon the receipt of the message and subsequent parsing for distinguishing a BR 
message from a non-call-control message that is exchanged between two adjacent ATM 
nodes. The BR message is a call-control message and the record content indicates a 
CALL control message. The preferred length of the Protocol Discriminator record 308 is 

15 1 octet (an octet consisting of 8 bits). The header 304 includes a Transaction 

Identification record 310. The Transaction Identification record 310 content identifies a 
specific BR message and distinguishes between multiple BR messages sent from one 
node to a specific adjacent node. The preferred length of the Transaction Identification 
record 310 is 4 octets. The preferred format of this record is identical to the ATM Forum 

20 defined CALL REF. The header 304 includes a Message Identifier record 312. The 

Message Identifier record 312 content for a BR message is unique and thus the Message 
Identifier record 312 indicates unambiguously whether the message is or is not a BR 
message. For a BR message, the content of the Message Identifier record 312 indicates a 




BR message. The preferred length of the Message Identifier record 312 is 1 octet. The 
message Identifier record 312 is located in the header at the same position as an ATM 
Forum message format message type, so that a node that is BR/BRC enabled will read the 
record as a BR message, and accordingly parse and interpret the remainder of the 
5 message as a BULK RELEASE message, specifically parsing the Number of Lists record 
318 (disclosed below) and treating the payload as a chain of lists, reading each field in 
the List, a list at a time. On the other hand, a node that is not BR/BRC enabled will find 
in the ATM Forum message format type element position an unknown message type, and 
will altematively discard the message, generate a Status message to the sender, or some 

10 other null action. 

The header 304 includes a Compatibility Instruction Indicator record 314. The 
Compatibility Instruction Indicator record 314 content indicates how to process the 
message as defined by the ATM Forum and understood by those skilled in the art. The 
preferred length of the Compatibility Instruction Indicator record 314 is 1 octet. The 

15 header 304 includes a Message Length record 316. The Message Length record 316 
indicates the total message length excluding header size. The preferred length of the 
Message Length record 316 is 2 octets. The header 304 includes a Number of Lists 
record 318. The Number of Lists record 318 indicates the number of connection records 
carried in the BR message, termed by the inventors "Lists" as taught below with 

20 reference to Figure 7. The construction and use of the Number of Lists record 318 is 
fiirther taught with reference to Figure 7. The preferred length of the Number of Lists 
record 318 is 2 octet. 



The BULK RELEASE message 302 payload 306 includes at least one list record, 
where each separate list record 328i is a record for a distinct connection "i", here 
portrayed as 3 Ust records 328a through 328c for respectively separate connections "a", 
"b", and "c". Each list record 328i includes a Call Reference Length field not shown 
generally but only with reference to list record 328a as 332a. The content of the Call 
Reference Length field 332a specifies the maximum value of the field "Call Reference 
Value" disclosed presently. The value is preferably in bytes. Suppose it is 3 bytes. 
Therefore the Call Reference Value can range from 0 to 2 to the power of 3 times 8 bits, 
i.e. from 0 to 16,777 K. The preferred length of the Call Reference Length field is 1 
octet. Each list record 328i includes a Call Reference Value field not shown generally 
but only with reference to list record 328a as 334a. The content of the Call Reference 
Value field 334a specifies a unique identification for each connection between 
connecting nodes. Illustratively, in the network portrayed in Figure 1, the content of the 
Call Reference Value field may be identified uniquely between gateway 102 and node 
104 illustratively as 34, between node 104 and node 106 illustratively as 200, between 
node 106 and node 108 illustrafively as 45, between node 108 and gateway 110 
illustratively as 67. Thus the Call Reference Value field identifies a connection that goes 
between adjacent nodes. The preferred length of the Call Reference Value field is 3 
octets. Each list record 328i includes a Cause Location field not shown generally but 
only with reference to Hst record 328a as 336a. The content of the Cause Location field 
336a specifies a coded categorization of connection clearing cause. The preferred length 
of the Cause Location field is 1 octet. Each list record 328i includes a Cause Value field 
not shown generally but only with reference to list record 328a as 338a. The Cause 
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Value field 338a indicates whether the connection clearing is to occur at the User side or 
the Network side. The preferred length of the Cause Value field is 1 octet. 

Referring to Figure 4, an embodiment of the BULK RELEASE COMPLETE 
message 402 includes an ATM User-to-Network Literface (UNI) formatted message. 
While a specific preferred embodiment of a BULK RELEASE COMPLETE message is 
disclosed within this patent, the invention is specifically not dependant upon any one 
specific embodiment of a BULK RELEASE COMPLETE message. The purpose of the 
BULK RELEASE COMPLETE message is to notify another network node that a 
clearance of specified connections is to occur or has occurred on a referenced node, in 
response to a BULK RELEASE message that has been received by the referenced node, 
as well as to optionally provide the data to access the connection and transaction data in a 
memory, and to store data in the memory associated with the transaction and or 
connection(s). Thus, a BULK RELEASE COMPLETE message should be in a format 
that will be distinguished and read by other network nodes, and should transmit the 
necessary information. There is no specific necessary embodiment of the BULK 
RELEASE COMPLETE message. 

The BULK RELEASE COMPLETE message is generated by a node upon a 
receipt of a BULK RELEASE message and a clear of the connections to that node carried 
in the BULK RELEASE message, as taught with reference to Figure 8 below. The BRC 
message includes a conventional message format having both a header 404 and a payload 
406. 

The BULK RELEASE COMPLETE message 402 header 404 includes a Protocol 
Discriminator record 408. The Protocol Discriminator record 408 content indicates 
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whether or not the message is an ATM signaUng CALL control message. The indication 
of this record is useful upon the receipt of the message and subsequent parsing for 
distinguishing a BRC message from a non-call-control message that is exchanged 
between two adjacent ATM nodes. THE BRC message is a call-control message and the 
5 record content indicates a CALL control message. The preferred length of the Protocol 
Discriminator record 408 is 1 octet. The header 404 includes a Correlation Identification 
record 410. The Correlation Identification record 410 content indicates a specific BRC 
message and is set equal to, by preferably copying back from, the Transaction 
Identification record 310 content of the received BR message (taught with reference to 

10 Figure 3), that is a trigger of the necessary processing for generation of the BRC 
message. The Correlation Identification record 410 enables a receiver of the BRC 
message to identify that a particular BRC message is the response to a specific BR 
message (or that a particular transaction/connection(s) clearing in the BRC generating 
node is related to a particular transaction/connection(s) clearing in the BR generating 

15 node). The preferred length of the Correlation Identification record 410 is 4 octets and 

has a format identical to the ATM Forum defined CALL REF. The header 404 includes a 
Message Identifier record 412. The Message Identifier record 412 content for a BRC 
message is unique and thus the Message Identifier record 412 indicates unambiguously 
whether the message is or is not a BRC message. For a BRC message, the content of the 

20 Message Identifier record 412 indicates a BRC message. The preferred length of the 

Message Identifier record 412 is 1 octet. The message Identifier record 312 is located in 
the header at the same position as an ATM Forum message format message type, so that 
a node that is BR/BRC enabled will read the record as a BRC message, and accordingly 
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parse and interpret the remainder of the message as a BULK RELEASE COMPLETE 
message. On the other hand, a node that is not BR/BRC enabled will find in the ATM 
Forum message format type element position an unknown message type, and will 
altematively discard the message, generate a Status message to the sender, or some other 
null action. 

The header 404 includes a Compatibility Instruction Lidicator record 414. The 
Compatibility Instruction Indicator record 414 content indicates how to process the 
message as defined by the ATM Forum and understood by those skilled in the art. The 
preferred length of the Compatibility Instruction Indicator record 414 is 1 octet. The 
header 404 includes a Message Length record 416. The Message Length record 416 
indicates the total message length excluding header size. The preferred length of the 
Message Length record 416 is 2 octets. The header 404 includes a Number of Lists 
record 418. The Number of Lists record 418 indicates the number of connection records 
carried in the BRC message, termed by the inventors "Lists" as taught below with 
reference to Figure 8, as well as with reference to Figure 7 for the BR message. The 
preferred length of the Number of Lists record 418 is 2 octet. 

The BULK RELEASE COMPLETE message 402 payload 406 includes at least 
one list record, where each separate list record 428i is a record for a distinct connection 
"i", here portrayed as 3 list records 428a through 428c for separate connections "a", "b", 
and "c". Each Ust record includes separate fields. The preferred fields for the BULK 
RELEASE COMPLETE message 402 payload 406 are the fields Call Reference Length 
field (not shown generally but only with reference to list record 428a as 432a), the Call 
Reference Length field (not shown generally but only with reference to list record 428a 
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as 432a), the Call Reference Value field (not shown generally but only with reference to 
list record 428a as 434a), the Cause Location field (not shown generally but only with 
reference to list record 428a as 436a), and the Cause Value field (not shown generally but 
only with reference to hst record 428a as 438a). As taught with reference to Figure 8, 
5 these four fields are each preferably set to the same content as the corresponding BULK 
RELEASE message record but it is specifically contemplated that the content of these 
four fields may be otherwise determined by the BULK RELEASE COMPLETE message 
generator, particularly if the node does not clear the same connections as the peer node 
generating the BR command. The content of the Call Reference Length field 432a 

10 specifies the maximum value of the field "Call Reference Value" disclosed presently. 
The value is preferably in bytes. Suppose it is 3 bytes. Therefore the Call Reference 
Value can range from 0 to 2 to the power of 3 times 8 bits, i.e. from 0 to 16,777 K. The 
preferred length of the Call Reference Length field is 1 octet. The content of the Call 
Reference Value field 434a specifies a unique identification for each connection between 

15 connecting nodes. Illustratively, in the network portrayed in Figure 1, the Call Reference 
Value may be identified uniquely between gateway 102 and node 104 illustratively as 34, 
between node 104 and node 106 illustratively as 200, between node 106 and node 108 
illustratively as 45, between node 108 and gateway 110 illustratively as 67. Thus the Call 
Reference Value field identifies a connection that goes between adjacent nodes. The 

20 preferred length of the Call Reference Value field is 3 octets. The content of the Cause 
Location field 436a specifies a coded categorization of connection clearing cause. The 
preferred length of the Cause Location field is 1 octet. The Cause Value field 438a 
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indicates whether the connection clearing is to occur at the User side or the Network side. 
The preferred value of the Cause Value field is 1 octet. 

Referring to Figure 5, a node maintains a connection database for connections 
included in a BULK RELEASE message termed herein DSl 510. The criteria for 
deleting a connection record from the database DSl 510 is dependant upon design 
considerations of a specific network, and will be well known to those skilled in the art. 
The database DSl 510 facihtates the generation and processing of both the BULK 
RELEASE and the BULK RELEASE COMPLETE message. The database DSl 510 
maintains a record of relevant connection data for each connection for which a BULK 
RELEASE message has been generated. The database DSl 510 preferably has the Call 
Reference Value 515 that uniquely identifies each connection for a quantity of 
connections determined by the Call Reference Value 515 bit length, and taught with 
reference to the content of the Call Reference Value field 334a, as the key data base 
index. Moreover, preferably each call reference 515 is associated with the BR message 
that transmitted its node clearance, preferably the Transaction Identification 520 that 
uniquely identifies each separate BR message for a quantity of BR messages determined 
by the Transaction Identification 520 bit length, and taught with reference to the content 
of the Transaction Identification record 310, as a data base root. 

Referring to Figure 6, a node maintains a connection database for connections 
included in a BULK RELEASE message for which a BR message has been generated 
but for which a BULK RELEASE COMPLETE MESSAGE has not yet been received 
(and processed by the software that maintains the database), termed herein DS2 610. The 
database DS2 preferably has the Transaction Identification 520 as the key data base 
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index, taught with reference to Figure 5. The record corresponding to each Transaction 
Identification 520 in database DS2 610 preferably points to the root of the database DSl 
710 (portrayed with reference to Figure 5) that contains all the connection references 
(preferably the Call Reference Value 515) sent in a BULK RELEASE message having 

5 the same Transaction Identification 520. Referring now to both Figure 5 and Figure 6, 
The preferred database organization of DSl 510 and DS2 610 is efficient for searching 
and processing call records when a BRC message is received. The maximum depth of 
DSl 510 is log2(N) and the maximum depth of DS2 610 is log2(N/n), where "N" is the 
maximum number of connections allowed in the node at a time, and "n" is the number of 

10 call references included in a BR message. 

Referring to Figure 7 and Figure 8, a BR and BRC message are used to request 
release of more than one connection. The called party or the calling party issue the BR 
message and it is transmitted along the signaling path. In general, BR and BRC are 
exchanged between a node A and a node B to release a plural number of connections 

15 (although only 1 connection is also feasible) that go between node A and node B. 

Referring specifically to Figure 7, a node responds to an initiating event at block 
704 by both clearing specific connections at the node, and building a BULK RELEASE 
message for those connections. The initiating event indicates a requirement for a clearing 
of a plural number of connections at a node. The initiating event may include, but is not 

20 limited to: a) a received Physical interface reset command, b) a received Virtual interface 
reset command, c) a received Datalink Layer Service-Specific Connection-Oriented 
Protocol (SSCOP) reset, d) a received Global path ATM Forum defined RESTART 
message, e) a received Virtual Path ATM Forum defined RESTART message, f) a 
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received plural quantity of RELEASE messages (that may occur in response to a period 
of network congestion), and g) a received Force Reroute in a Semi-Permanent Switched 
Virtual Circuit (SPVC) based network. 

In block 708, a specific transaction Identification is built for a peer node set of 
5 connections to be cleared. It is specifically contemplated that more than one transaction 
may be needed to clear a specific node to need connection set. For the specific peer node 
transaction being cleared, the node builds and adds the Transaction Identification 520 
root to the database DSl 510 at block 712. For the specific peer node transaction being 
cleared, the node builds and adds the Transaction Identification 520 root to the database 

10 DS2 520 at block 716. For each connection to be cleared, in accordance with the 

initiating event, the node selects a connection for preparation of a List as shown at block 
720 for a specific connection, in a loop that iterates for each connection. At block 724, 
the BLOCK RELEASE message record 328i is prepared for the connection being 
iterated, by setting each of the fields in a record 328i taught with reference to Figure 3, 

15 specifically the Call Reference Length field 332i, the Call Reference Value field 334a, 
the Cause Location field 336a, and the Cause Value field 338a (with reference to record 
"a" in Figure 3. At block 728, the prepared BR message record List 328i is appended to 
the payload 306. At block 732, connection data, including specifically the Call Reference 
Value 515 which is the preferred key index is added to the database DSl 510 in 

20 accordance with the Transaction Identification 520 root. At block 736, the at least 

connection identifier in the embodiment of the Call Reference Value 515 is added to the 
database DS2 510 including a pointer to the same connection in the database DSl 510, 
preferably by pointing to the transaction Identificafion 520 root in the database DSl 510. 
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At block 740, the method illustrated with respect to blocks 720, 724, 728, 732, and 736 
is repeated for a new connection, until a List has been prepared for each connection to be 
cleared by the BLOCK RELEASE message, and the records have been added to both the 
database DSl 510 and the database DS2 520. 

At block 744, the number of Lists for insertion into the Number of Lists record 
318 that is taught with reference to Figure 3 is calculated. At block 748, the message 
length for insertion into the Message Length record 316 that is taught with reference to 
Figure 3 is calculated by summing the size of each List built in blocks 724. At block 752 
the BULK RELEASE message header 304 is built by setting the Protocol Discriminator 
record 308, the Transaction Identification record 310, the Message Identifier record 312, 
the Message Identifier record, the Compatibility Instruction Indicator record 314, and the 
Message Length record 316 taught below with reference to Figure 3. At block 756, each 
connection included in the BR message is cleared fi-om the node. A clearing has the 
same general meaning as for the conventional RELEASE message, generally involving 
freeing up resources on the node and informing peer node(s) that hold the same 
connection. At block 760, the built BULK RELEASE message is sent to a peer node 
across a signal path. 

Referring to Figure 8, at block 804, a node enabled to receive a Bulk Release 
message responds to the receipt of a BULK RELEASE message fi^om a connected peer 
node by both clearing specific connections at the node, and building a BULK RELEASE 
COMPLETE message for those connections in succeeding acts. At block 808, for each 
List record in the received BULK RELEASE message, the node clears the connection in 
a loop that includes block 808, block 812, and block 816, and that iterates once through 
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the loop for each connection. Each connection is preferably identified by the content of 
the Call Reference Value Field 334i in the List record. Each record contains data for a 
distinct connection to be cleared as taught with reference to Figures 3 and 5. At block 
812, the BRC message record 428i is prepared for the connection being iterated, by 
5 setting each of the fields in the payload 406 taught with reference to Figure 4, specifically 
the Call Reference Length field 432i, the Call Reference Value field 434i, the Cause 
Location field 436a, and the Cause Value field 438a. At block 816, the prepared BRC 
message record List 428i is appended to the payload 406. At block 820, the method 
illustrated with respect to blocks 808, 812, and 816 is repeated for a new connection, until 

10 each connection has been cleared and a List has been prepared and appended to the 
payload 806 for each cleared (or to be cleared, depending upon the embodiment) 
connection, and the prepared for connection to be cleared by the BLOCK RELEASE 
COMPLETE message. 

At block 824, the Transaction Identification record 310 received in the BULK 

15 RELEASE message header is copied into the Correlation Identification record 410 of the 
BULK RELEASE COMPLETE message header 404. At block 828, the number of Lists 
for insertion into the Number of Lists record 418 is calculated. At block 832, the 
message length is calculated by adding the size of each List. At block 836, the BULK 
RELEASE COMPLETE message header 404 is built by setting the Correlation 

20 Identification record 410, the Compatibility Instruction Indicator record 414. the Message 
Length record 416, and the Number of Lists record 418 in the BULK RELEASE 
COMPLETE message header 404. At block 840, the BULK RELEASE COMPLETE 
message is sent to the peer node via the data link layer. At block 844, the peer node 
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receives and reads the BULK RELEASE COMPLETE message. At block 848, the peer 
node deletes each connection record for the BULK RELEASE COMPLETE message 
from the database DS2 520, and updates a status record in the database DSl 510. 

Now, referring again to Figure 2, supposing again that the trunk that connects 
5 node 204 to node 206 is cut, so that each of the ten connections along path 1 should be 
released, node 204 can prepare and send a single BULK RELEASE message to router 
202 (assuming that router 202 supports the BULK RELEASE message) containing the 
ten Lists that have the call reference of each of the ten connections along path 1 between 
node 204 and router 202. Node 204 clears the ten connections at node 204 along path 1 
S 10 between node 204 and router 202, and router 202 upon receipt of the BULK RELEASE 
In message clears the ten connections at router 202 along path 1 between router 202 and 

S node 204, and prepares and sends a BULK RELEASE COMPLETE message to node 

f 204. 

Similarly, node 206 can prepare and send a single BULK RELEASE message to 
yS 15 node 208 (assuming that node 208 supports the BULK RELEASE message) containing 
□ the ten Lists that have the call reference of each of the ten connections along path 1 

between node 206 and node 208. Node 206 clears the ten connections at node 206 along 
path 1 between node 206 and node 208, and node 208 upon receipt of the BULK 
RELEASE message clears the ten connections at node 208 along path 1 between node 
20 206 and node 208, and prepares and sends a BULK RELEASE COMPLETE message to 
node 206. Similarly, node 208 can prepare and send a single BULK RELEASE message 
to router 216 (assuming that router 216 supports the BULK RELEASE message) 
containing the ten Lists that have the call reference of each of the ten connections along 
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path 1 between node 208 and router 216. Node 208 clears the ten connections at node 
208 along path 1 between node 208 and router 216, and router 216 upon receipt of the 
BULK RELEASE message clears the ten connections at router 216 along path 1 between 
node 208 and router 216, and prepares and sends a BULK RELEASE COMPLETE 
message to node 208. 

In the foregoing specification, the invention has been described with reference to 
specific exemplary embodiments thereof. It will however be evident that various 
modifications and changes may be made thereto without departing from the broader spirit 
and scope of the invention as set forth in the appended claims. The specification and 
drawings are accordingly to be regarded as illustrative rather a restrictive sense. 



23 



